Язык блоков и дуг в SADT описывает все функции, и объекты системы и, следовательно позволяет раскрыть функциональное содержание системы. Однако иногда графика функциональной SADT-модели недостаточно описывает, как именно действует система. Обратите внимание, мы сказали "недостаточно", а не "неточно". Правильно созданная проверенная функциональная SADT-модель точно описывает функциональное содержание системы со статической точки зрения, но этого может оказаться недостаточно для описания других аспектов работы системы и ее поведения, необходимых для полного понимания того, как она должна функционировать. Свойства системы и правила выполнения ее функций - вот два наиболее общих аспекта такого рода. Свойства - это численные и текстовые описания характеристик функций и данных системы. Действия определяют, что необходимо для того, чтобы функции выполнялись правильно, и каковы результаты их выполнения. Используя понятия свойств и действий, SADT предоставляет возможность уточнять диаграмму с помощью примечаний, описывающих ее динамику. Записи таких примечаний оживляют модель.

Свойства - это нефункциональные характеристики, именованные величины, описывающие некоторые важные аспекты объектов и функций системы. Например, к свойствам объектов относятся скорость, объем и частота доступа. Свойства функций часто включают место, время и частоту их выполнения. Свойства статичны по времени. Например, базы данных имеют фиксированные размеры с ожидаемой и устойчивой скоростью наполнения в течение некоторого периода времени. Чтобы было яснее - пол в цехе можно рассматривать как базу данных, поскольку он является вместилищем с ограниченным количеством помещений, которые заполнены до определенного возможного уровня станками и их рабочими зонами.

Свойства очень важны, потому что они связаны с требованиями системы, которые должны удовлетворяться, иначе система не будет правильно функционировать. Например, время, которое затрачивает угольный ликвационный реактор на обработку определенной порции угля, зависит от веса и качества угля. Для этой системы свойства угля и время ликвации - критические требования. То же относится и к контролю качества в механическом цехе. Справочник стандартов качества и точки контроля на чертеже - это то, что управляет качеством выполнения задания в экспериментальном механическом цехе. Без этих ограничений цех не сможет производить детали для новых моделей самолетов.

Не удивительно, что понимание системы будет не полным, пока не определены свойства функций и объектов. SADT требует, чтобы свойства определялись с использованием так называемых "меток свойств". Метка свойства - это замечание "с квадратом", соединенное с блоком или дугой с помощью зигзагообразной линии и описывающее это свойство. Описания не всех свойств конкретного блока или дуги помещаются на диаграмму, а только тех, которые проясняют содержание диаграммы. Например, на рис. 19-1 показано, как используются метки свойств для описания стандартной частоты выполнения функций в ходе выполнения работ с рабочим комплектом. Эти метки присоединены к блокам диаграммы.

На рис. 19-1 видно, как всего несколько меток могут подчеркнуть суть диаграммы. Однако для полноты для каждого блока или дуги должен составляться глоссарий, связанный с их свойствами. Наш опыт показывает, что помещение информации такого рода из глоссария в словарь данных - надежный способ записать эти сведения. Таким образом, описания свойств всегда доступны и их легко находить.

Вспомните, что функциональные диаграммы SADT - это диаграммы ограничений, потому что они отражают ограничения, накладываемые функциями системы друг на друга. Законченная функциональная диаграмма дает моментальный снимок всех дуг управления, которые ограничивают функцию в какой-либо момент работы системы. Поэтому, вообще говоря, не все ограничения на функцию действуют одновременно. В большинстве случаев только некоторые ограничения на каждую отдельную функцию действуют в какой-либо момент времени. SADT определяет "действие" как вид работы функции после того, как она "включается" посредством некоторых ее входов или управлений для создания выходов. Таким образом, каждое конкретное действие использует не все возможные управления и входы и производит не все возможные выходы. Количество возможных действий функции зависит исключительно от количества возможных взаимодействий ее данных, а не от количества входящих в блок дуг. Позже об этом будет сказано подробнее.

Описание правила действия в SADT - это примечание (сходное с принятыми в формальных грамматиках), которое описывает отдельную комбинацию управления, входа и выхода для некоторой функции конкретной модели. Правила действия включают номер блока, уникальный идентификатор действия, предусловия и постусловия. Каждое правило действия для модели формулируется в соответствии с синтаксисом:

[Модель/] блок * действие : предусловия--> постусловия

Блок и действие дают правилу уникальное имя. Блок идентифицирует определенный блок модели. Действие идентифицирует одно правило действия для этого конкретного блока. Поэтому сочетание блок и действие однозначно идентифицирует одно правило действия в модели. Одновременно могут рассматриваться правила действия для более чем одной модели. В таком случае модель, точнее имя той модели, к которой относится правило, пишется в начале правила. Предусловия и постусловия - это то, что требуется для действия и что является его результатом. Обобщая, можно сказать, что каждое правило действия может быть интерпретировано следующим образом.

Рис. 19-2. Функция, имеющая единственное правило действия

Для функции блок правило действия действие определяется так: если истинны предусловия, выполняется функция блок и делает истинными постусловия.

Как предусловия, так и постусловия представляют собой логические выражения, построенные с помощью ICOM-кодов, где каждый ICOM-код идентифицирует единичную дугу управления, входную или выходную дугу конкретного блока. Логические операторы AND, OR и NOT вместе со скобками представляют средства для записи различных сложных логических выражений. Например, на рис. 19-2 показан блок диаграммы ЭМЦ/А2, у которого только одно правило действия. Это правило утверждает, что функции. подготовить рабочее место необходимы выбранное инструменты, станки в цехе, чертеж и указания, чтобы рабочий подготовил оборудованное рабочее место. Это пример правила действия, которое утверждает необходимость участия всех входных дуг, дуг управления и выходных дуг в действии конкретного блока.

Часто возникают ситуации, в которых для правильного действия блока необходимо отсутствие одной или нескольких дуг. Дуги, не участвующие в конкретном действии, отмечаются горизонтальным штрихом (символизирующим NOT) над ICOM-кодом, если они входят в предусловие. Это означает, что объекты, представляемые этой дугой, должны отсутствовать для того, чтобы действие было выполнено. Например, действие 3 на рис. 19-3 утверждает, что план выполнения заданий не должен быть представлен в момент оценки задания, который предшествует приемке.

Рис. 19-3. Функция, имеющая несколько правил действия

Встречаются также ситуации, когда только некоторые из дуг используются в процессе действия для производства выходов. Если входная дуга или дуга управления не участвуют в действии, они просто опускаются в предусловии. Аналогично если только часть выходов блока производится во время действии, то ICOM-коды для этих не создаваемых выходов опускаются в постусловиях. Например, отсутствие 02 и 03 в действии 4 означает, что в процессе этого действия вырабатывается только статус задания.

Иногда функции полностью используют свои входы или управления в процессе действия. В таких случаях эти входные дуги и дуги управления перечисляются в постусловии со штрихом отрицания NOT над ними. Это означает, что объекты, представленные данными дугами, использованы во время действия функции и недоступны для других блоков или будущих действий.

Иногда аналитику трудно определить все способы действия функции в процессе работы системы. В этих случаях мы рекомендуем воспользоваться приемом построения таблиц истинности, первоначально разработанный в логическом исчислении высказываний и часто применяемый в общей теории систем.

Действие каждого блока описывается таблицей истинности, представляющей собой декартово произведение всех возможных сочетаний присутствия (отмечаемого с помощью "true" или Т) и обязательного отсутствия (отмечаемого с помощью "false" или F) входных дуг, дуг управления и выходных дуг. Каждый столбец такой таблицы становится тогда потенциальным правилом действия. (Иногда не имеет значения, принимает ли конкретная дуга участие в действии. В этих случаях представляется разумным использование буквы D. Однако запомните, что для полного отражения декартова произведения потребуется существенное увеличение размера таблиц.)

Обычно не все, что входит в таблицу, становится правилом действия, но каждое действие в таблице определено. Например, в табл. 19-1 представлено декартово произведение с отсутствующими или присутствующими дугами для блока подготовить рабочее место. Для экспериментального механического цеха реален только случай 1, когда все входные дуги и дуги управления участвуют в действии. Попробуйте применять этот

прием, когда вы точно не знаете, как выполняется конкретная функция моделируемой вами системы.

Метки свойств в SADT описывают конкретные аспекты системы. Они помещаются на диаграмме в виде примечаний, часто как подготовительный этап к созданию спецификации модели. Правила действия в SADT кодируют набор возможных действий блоков модели. Иногда для какого-либо блока эти правила трудно определить. В этом случае для создания полного набора возможных действий мы советуем использовать методы, применяемые в логическом исчислении.

Dickover, M., and С. McGowan: "Software Design Using SADT", SofTech Technical paper TP061, August 1977.

Mendelson, E.: Introduction to Mathematical Logic, VAn Nostrand Reinhold, New York, 1964.

Martin, J., and C. McClure: Diagramming Techniques for Analysts and Programmers, Prentice-Hall, Englewood Cliffs, N.J., 1985.

Parnas, D.: "On the Criteria to be Used in Decomposing Systems into Modules", CACM, December 1972.

Ross, D.: "An Essay on Activity Diagramming", SofTech Technical Report no. 7104, November 1976.

Ross D.: "Structured Analysis (SA): A Language for Communicating Ideas", IEEE Transactions on Software Engineering, vol. 3, no. 1, January 1977.

Schoman, K.: "SADT and PERT", SofTech Deliverable no. CLIN#0-02AG, November 1977.

SofTech, Inc.: "The DWS/CS Emergency Preset Structured Specification", Technical Paper no. 1083-1, August 1981.

Savith, W.: Abstract Machines and Grammars, Litt;e, Brown, Boston, 1982.

Weinberg, G.: An Introduction to General Systems Theory, John Wiley, New York, 1975.

Weinberg, G.: Rethinking Systems Analysis and Design, Little Brown, Boston, 1982.